Обсуждение:Type library

Правки, искажающие смысл

Александр Дмитриев, будем играть в войну правок?

Хватит вносить правки, которые искажают смысл, прикрываясь добрыми намерениями и стилем. В википедии в статьях ценится в первую очередь содержание, а уже во вторую — оформление. Никие стилевые улучшения не ценны, если они портят смысл.

Претезнии.

Было стало:

В соответствии с этим, важнейшей характеристикой типоописания является вид типоописания (англ. Type Kind), который устанавливает, чем является описываемая данным типоописанием сущность.

Стало:

То, какая именно сущность определяется, устанавливает вид типоописания (англ. Type Kind).

Во-первых, полученный вариант стилистически менее правилен. Во-вторых, потеряно слово «вид». Что значит «то, какая именно». «Какая именно» — это слишком широкий квалификатор. Важен только вид сущности. В третьих, потеряно слово «важнейшей». Это не чрезмерное преукрашивание, это характеристика действительно важнейшая: без её типоописание полностьб бесполезно, так как два одинаковых типоописания с разными typekind-ами могут определять совершенно разные сущности. Кроме того, она является важнейшей даже в том плане, что именно с анализа этого свойства начинается работа с типоописанием. Код получает typekind типоописания, и в зависимости от значения typekind-а определяется, какой код будет дальше разбирать типоописание.

Я возмущён тем, что абзац о 8 видах оторван от таблицы левым абзацем, который, в свою очередь, оторван от своего абзаца («базовые характеристики»). Информация об уникальных идентификаторах, по идее, должна была продолжить маркированный список выше. И она бы продолжила его, если бы тот факт, что идентификаторы разных элементов имеют разные названия в зависимости от рода элемента и вида типоописания, если элемент является типоописанием. Поэтому информация была выделена в отдельной абзац. Но абзац шёл сразу же после списка, продолжая тему базовых характеристик.

Этот абзац начинается с фразы «кроме того». Кроме чего «того»? В моём случае, поскольку абзац шёл после списка, под «того» понимался список. И действительно, кроме имени, докстринга и хелпинформации только идентификатор может считаться базой характеристикой. Это единственная характеристика, которая и у библиотеки, и у любого типоописания и у любоого метода.

Перенеся абзац, ты разрушил связь между списком и абзацем. И у тебя «кроме тогою» относится уже к информации о 8-ми видах. Или к typekind-у. Получается, что кроме typekind-а есть ещё такая базовая характеристика, как уникальный идентификатор. Но это грубейшая ошибка, потому что typekind не является базовой характеристикой — он есть только у типоописаний. В то время как идентификатор, повторяюсь, есть у элементов любого рода (уровня). Да плюс этой перестановкой ещё и оторвал таблицу от абзаца о 8-ми типах.

Зачем?

Протестую против переименования колонки «Type Kind» на «Вид типоописания». В данном случае, это не «неоправданное использование английских терминов», а имя параметра. Имя конкретного параметра. Почти что как имя переменной. Это не переводится. Ведь тебе не приходит в голову переводить и менять com_print_typeinfo на ком_напечатать_типоописание? В данном случае, перевод столь же неправомерен. Слова «Type Kind» идентифицируют на абстрактное понятие вид типоописание, а конкретный параметр, который так называется. А ниже перечисляются столь же конкретный константы. Тогда, если уж придерживаться такой радикальной логике (переводить всё, что переводится), надо было и константы из этой колонки по-переводить? :$

Зачем убирать ссылку со слова «класс» из ячейки «COM-класс»?

Почему примечание перенесено со слова «продвинутым» на словосочетание «заголовочных файлов». Ведь оно (примечание) призвано ответить на удивление/протест сишников, особенно тех, кто незнаком с COM или вообще разрабатывает не под Windows: —Да как они смают сравнивать заголовочные файлы и какие-то жалкие библиотеки типов?! Чем это она продвинута?! —А вот, уважаемый, прочитай примечание и узнайте, чем.

Теперь реф стоит так, как будто поясняет словосочетание «заголовочные файлы», которое уж точно не надо пояснять, так как оно является ссылкой — кому непонятно, пройдут по ссылке и прочитают.

Аналогично: почему примечание перенесено со слова «обычных» на словосочетание «API-функций». Ведь оно (примечание) призвано ответить на вопрос «Что значит обычная? А что, бывают необычные функции?». Теперь она стоит так, как будто поясняет, что такое WinAPI-функции.

--Firehacker 22:25, 4 февраля 2010 (UTC)

Никакой смысл не ценен, если он не нейтрален. Полученный вариант стилистически более правилен, так как в нём нет субъективной и ненейтральной оценки характеристики как "важнейшей". Почему в статье Библиотека не написано "важнейшее учреждение...", ведь оно такое важное, столько знаний даёт людям.

"Какая именно" в данном контексте означает "Какого именно вида", так как перед этим упомянуто об этих самых видах. Пример. Коровы бывают молочные и мясные. То, с какой именно коровой вы имеете дело, можно определить по таким-то признакам. У меня просто вопрос и ответ стоят менее точно. Пример. Что летит? Вертолёт. <-?-> Что летит? Ми-8. -> Какая корова? Мясная. <-?-> Какая корова? Бурёнка. -> Какая сущность? Обычный модуль. <-?-> Какая сущность? Модуль "Тра-ля-ля". Для ответа на вопрос "какая" подойдёт любая информация об объекте, в том числе любой точности. Слово "именно" заставляет вспомнить упоминавшуюся ранее неопределённость в видах сущности, чтобы показать точность вопроса "какая". Это я объяснил почему я написал именно так. Вообще же, я согласен на вариант "То, какого вида сущность определяется, устанавливает вид типоописания", но просто он какой-то корявый.

Абзац о 8 видах я перенёс выше потому, что в левом абзаце упоминается понятие "вид типоописания", но оно ещё не объяснёно читателю, и как раз объясняется в абзаце о 8 видах. В общем, тут куча всяких смысловых связей между различными местами, и в линейную структуру не укладывается. Тогда единственное, что возможно - это просто перечислить всю эту информацию в таком порядке, чтобы смысловым связям приходилось как можно меньше тянутся. "Кроме того", согласен, не в тему, лучше убрать.

То, что в заголовке столбца "Type Kind" - это имя параметра, сразу не понятно. По умолчанию, любой текст, подходящий под какой-нибудь естественный язык, понимается как текст на этом естественном языке. Если перед этим происходит какая-то договорённость, что такой-то текст - это не текст на естественном языке, а какой-то символ, то он уже понимается как этот символ. Определения/договорённости ранее не было, поэтому я его и распознал как текст на английском языке и перевёл. Читателю тоже, скорее всего, будет непонятно, что это имя параметра, а не упоминавшийся ранее английский термин "Type Kind". Думаю, после таблицы нужно указать: "В третьем столбце указан параметр такой-то функции или такого-то метода..."

Ссылку со слова "класс" я убрал, потому что ранее в статье уже встречается ссылка на статью "Класс (программирование)". см. WP:LINKS#Repeated_links

Примечание может относиться не только к слову, следующему перед ним, но и к словосочетанию, следующему перед ним, и к грамматической основе, следующей перед ним, и к предложению, следующему перед ним. Из четырёх вариантов лучше выбирать наибольший из возможных. Если примечание относится к предложению (про продвинуную аналогичность), то примечание ставится в конце предложения, если оно относится к словосочетанию ("обычных WinAPI-функций"), то ставится в конце словосочетания.

--Александр Дмитриев 04:30, 5 февраля 2010 (UTC)

Да я прекрасно знаю положения об НТЗ. Пример с библиотекой не тождественный. Это действительно субъективный критерий, потому что я (и любой другой) может оспорить, что библиотека является важнейшей. «Вот я ни разу в жизни не пользовался библиотеками, но ведь я живу и радуюсь».

Критерий «важнейшести» TypeKind'а совершенно не субъективен: TypeKind — важнейшая характеристика, потому что всё остальное теряет смысл без её отсутствия.

Натянутый пример: Важнейшей характеристикой слова «gut» является язык этого слова. В рамках этого примера язык действительно имеет первостепенное значение, потому что от него, при одинаковости формы, зависит содержания. Если это английский язык — то имеются в виду кишка, если нецеский — слово означает «хороший», если венгерский — «тормозной». Каким бы не был язык, слово выглядит одинаково, имеет одни и те же внешние признаки. Но делать какой-то анализ слова, судить его грамматических признаках, о его значении можно исключительно после того, как будет указан язык. Без знания языка это просто набор букв. При разных языках эти буквы означают совершенно разные вещи, а без указания языка вообще ничего не означают. Так и с TypeKind-ов: одни и те же данные типоописания при разных значениях TypeKind-а могут означать совершенно разные вещи. А без TypeKind-а эти данные вообще не имеют смысла.

Другой пример: если бы сущности были электронными компонентами, и их хранили в усреднённых контейнерах (аналогичны типоописаниям), на которых бы писался вид компонента, номинал, погрешность номинала, температурный диапазон и т.п., то важнейшей характеристикой был бы «вид компонента». Потому что необладание информацией о виде компонента лишает смысла и какой-либо значимости все остальные. Ну номинал 20 единиц. Ну погрешность указания номинала 5 процентов. Ну температурный диапазон -50—+70. А что за компонент-то? И что, что 20 единиц? Какой смысл в этом сведении, если неизвестен вид компонента? Может быть это двадцатиомный резистор, т.е. номинал определяет сопротивление? А может быть это двадцатифарадный ионистор, то есть номинал определяет ёмкость? А может быть диод с максимальным обратным напряжением 20 вольт? А может быть это трансформатор с коэффициентом трансформации 20? Понимаешь, что в зависимости от типа элеменета, параметр номинал может определять существенно разные вещи.

В данном случае важность и значимость основывается не на каких-то личных критериях и суьъективных оценках. В данном случае она расчитывается здравыми объективными логическими рассуждениями.

Абзац о 8 видах я перенёс выше потому, что в левом абзаце упоминается понятие "вид типоописания", но оно ещё не объяснёно читателю, и как раз объясняется в абзаце о 8 видах. В общем, тут куча всяких смысловых связей между различными местами, и в линейную структуру не укладывается. Тогда единственное, что возможно - это просто перечислить всю эту информацию в таком порядке, чтобы смысловым связям приходилось как можно меньше тянутся. "Кроме того", согласен, не в тему, лучше убрать.

В моём вариенте смысловой связи приходилось тянуться меньше всего. Я согласен с тем, что термин «вид типоописания» упомянут раньше, чем раскрыт. Я понимал это, когда писал статью. Именно по этому термин стоит в самом конце абзаца «Кроме того» и объясняется в сдедующем же абзаце «о 8 видах».

Читатель натыкается на нераскрытый термин, останавливается на нём («Стоп, а что это!?»), и видит расшифровку строкой ниже. Это не так критично. Это менее критично, чем ведёргивать из перечисления базовых характеристик одну очень важную и уносить её в конец текста. Даже если убрать «кроме того» и заменить на «Ещё одной базовой характеристикой», читатель возмутится: «Ага, написал о 4 базовых, об одной забыл, потом через час вспомнил и решил туд же нелепо приписать „ещё одной“? Фи!».

В общем, есть два требования:

1. Абзац о 8-ми видах и таблица с сущностями должны соседствовать.
2. Абзац об уникальном идентификаторе должен соседствовать со списком базовых характеристик. Потому что это тоже базовая характеристика.

Нарушать оба требования в угоду одному («сначала расшифровка, потом упоминание»), особенно если расшифровка идёт сразу же после упоминания — глупо.

То, что в заголовке столбца "Type Kind" - это имя параметра, сразу не понятно. По умолчанию, любой текст, подходящий под какой-нибудь естественный язык, понимается как текст на этом естественном языке. Если перед этим происходит какая-то договорённость, что такой-то текст - это не текст на естественном языке, а какой-то символ, то он уже понимается как этот символ.

Это сразу понятно из того, что столбец полностью заполнен конкретными константами.

Это всё равно что вот такая таблица, поясняющая один из параметров телевизора:

Volume	Громкость, сон
|	0
||	2
|||	4
||||	6
|||||	9
||||||	10

В данном случае нельзя переводить Volume ни в «Громкость», ни в «Уровень», ни во что другое. Потому что понятно, что имеется в виду не понятие как таковое, а конкретный параметр конкретного телевизора, измеряющийся в «столбиках». Человек, когда настраивает громкость, видит на экране:

VOLUME
||···

Соответственно, лучше всего, если над ячейками со столбиком будет стоять заголовок «Volume», тот самый, который пользователь телевизора видит на экране над этими же самыми столбиками.

А само словосочетание «вид типоописание» — ущербно. Я её ввёл исключительно из тех соображений, чтобы не писать везде, где оно встречается «вид сущности, описываемой данным типоописанием» или «значение параметра TypeKind».

Что касается указывания каких-то ссылок на конкретные параметры функций, я считаю, что в секции «Логическая структура» нельзя ссылаться на какие-то конкретные фуннкции.

По поводу «можно сказать». Зачем вырезать? Десятки статей используют этот оборот, и никто не нападает на эти статьи. Более того, я считаю, что вырезание «можно сказать» нарушает принцип НТЗ. Это утвереждение — лоческие обобщение сведений. Это утверждение — дань существуещему мнению. В отличие от всего остального (всё остальное написано в авторитетнейшем в данном вопросе источнике — в MSDN), этого утверждения там нет. Поэтому я категорически против того, чтобы утверждение не было снабжено фразой «можно сказать» или «существует мнение».

По поводу примечаний: если слово способно смутить определённый круг лиц, пояснять его надо сразу же, а ждать, пока возмущённый дочитает до конца статьи. Википедия не станет хуже, от того что примечанеи стоит на слове, а не в конце приложения. Зачем тогда править? Из вредности?

--Firehacker 06:51, 5 февраля 2010 (UTC)

Оценка "важнейший" не нейтральна в любом случае (вне зависимости от контекста), так как не существует критерия важнейшести (см. статью про нейтральную точку зрения). Про библиотеку тоже можно сказать, что без неё теряет смысл вся научная инфраструктура, например, государства. Можно употреблять слово "важный", но только с указанием того, "для кого важный" или "для чего важный" (потому что в противном случае будет казаться, что оно важно для автора). Это будет больше указывать функциональную роль, чем давать оценку (как раз то, что ты хотел). Например: "пихта одноцветная имеет важное значение для экономики западных штатов США" или "беркут имел очень важное значение в шаманском облачении древних алтайцев". Кстати, поэтому предлагаю первый абзац раздела "Значение" написать так: "TLB имеет важное значение как в разработке, так и в работе приложений" или "Информация, содержащаяся в TLB, имеет важное значение как в разработке, так и в работе приложений". (Последние слова можешь изменить, если считаешь, что я изменил смысл). В случае с TypeKind'ами предлагаю такой вариант: "В библиотеке типов могут описываться сущности 8-ми различных видов. Каждое типоописание определяет одну из них. То, какая именно (или "какого вида") сущность определяется, устанавливает вид типоописания. В соответствии с этим, вид типоописания является важной характеристикой для того-то, того-то."

Кстати, я правильно понял из твоих слов, что термин (что следует из выделения его курсивом) вид типоописания был введён тобой? Не орисс ли это? Яндекс выдаёт только твою тему в блоге на vbstreets, в которой я употребил это словосочетание, а Google - только на обсуждаемую статью. И по слову "типоописание" тоже ссылки только на vbstreets (твои посты) и эту статью.

Мне кажется, что требование «сначала расшифровка, потом упоминание» более важно, чем два других требования, потому что фактически употребление потенциально непонятного термина приводит к потенциально непонятному всему предложению, так как в предложении лежит весьма большая смысловая нагрузка на этот термин (значительная доля смысла предложения зависит от смысла этого термина). Также мне кажется, что твоя симпатия к твоему варианту больше моей симпатии к моему варианту, поэтому предлагаю использовать твой вариант.

Про столбец "Type Kind". Когда я читал статью, мне показалось непонятным значение этого столбца. Я просто высказал свой независимый взгляд, заключающийся в том, что название этого столбца потенциально может ввести в заблуждение (в которое я и попал, и результатом была ошибочная правка). Ты можешь учесть мой независимый взгляд со стороны, а можешь не учитывать. Если ты не хочешь упоминать конкретные параметры функций в разделе "Структура", то объяснение смысла столбца можно сделать в примечании. Кстати, ещё одна причина, по которой мне "Type Kind" показался употреблённым ранее английским термином, а не идентификатором - это то, что в идентификаторах (параметрах функций, именах переменных) обычно не бывает пробелов.

"Можно сказать" придаёт утверждению неопределённость, расплывчатость, неуверенность ("можно сказать, а можно и не говорить"), неоднозначность, что является уходом от научного стиля, поэтому я его и убрал. "Существует мнение" - намного лучше, и действительно улучшает нейтральность. Про десятки других статей: с других статей имеет смысл брать пример только если они хорошие или избранные, потому что только они по-настоящему отражают консенсус участников. Я вот сейчас из случайных 50 избранных статей не нашёл ни одной, в которой бы писалось "можно сказать".

Да, Википедия не станет хуже, если примечание поставить на слово, а не на предложение. Можешь исправить на свой вариант. Правилами это не регулируется. Просто мне кажется, что примечание нужно всегда ставить на длиннейшую из возможных синтаксических единиц. Опытный участник Виктория где-то когда-то (ну не смог я сейчас найти ту правку) подробно объясняла, почему так лучше. Ну я могу привести, например, такую аргументацию (возможно, это как раз частично её тогдашняя аргументация). Сноска внутри предложения (а тем более поставленная на конкретное слово) побочно выполняет ненужную функцию разделения. Для специального разделения используется запятая, а тут разделение происходит как побочное ненужное действие. Кроме того, вставленная сноска прерывает мысль. Лучше, чтобы читатель дочитал до конца мысли, а потом уже смотрел примечание к мысли.

А из вредности правят только вандалы.

--Александр Дмитриев 00:38, 7 февраля 2010 (UTC)

Оценка "важнейший" не нейтральна в любом случае (вне зависимости от контекста), так как не существует критерия важнейшести (см. статью про нейтральную точку зрения).

Существует. Когда нечто имеет строго ограниченный набор характеристик, и при этом одна из характеристик определяет суть и вообще наличие смысла у всех остальных характеристик, не является ли это критерием важнейшести этой первой характеристики?

Про библиотеку тоже можно сказать, что без неё теряет смысл вся научная инфраструктура, например, государства. Можно употреблять слово "важный", но только с указанием того, "для кого важный" или "для чего важный" (потому что в противном случае будет казаться, что оно важно для автора). Это будет больше указывать функциональную роль, чем давать оценку (как раз то, что ты хотел). Например: "пихта одноцветная имеет важное значение для экономики западных штатов США" или "беркут имел очень важное значение в шаманском облачении древних алтайцев".

Слово «важный» здесь как раз совсем неприменимо. Фразы «более важный», «менее важный» возможны, когда возможно сравнение. Например, можно спорить о том, что важнее: имя сущности или её уникальный идентификатор. Заявлять, что имя важнее идентификатора, или что идентификатор важнее имения — вот это было бы как раз нарушением НТЗ-принципа. Но когда есть два понятия, принадлежащих разным уровням организации, когда последующие зависимы от первого, важнейшесть первого не может быть поставлена под сомнение.

Кстати, по твоему, утверждение, что «Конституция — важшейший, первостепеннейший документ», — это тоже нарушение НТЗ?

Вообще, если бы в русском языке был другой адекватный перевод понятия «primary», я бы его и использовал. Но «первичная характеристика» — плохо, «первостепенная характеристика» — ещё хуже. Нет нормального аналога.

Могу заменить «важнейшей характеристикой является» на «характеристикой, имеющей первостепенное значение в вопросе определения дальнейшего хода анализа типоописания, сути описываемой им (типоописанием) сущности, а также значения ( ="смысла") всех его (типоописания) прочих характеристик, является». Эта непредвзятая «кишка» лучше предвзятого слова «важнейшей»?

Кстати, поэтому предлагаю первый абзац раздела "Значение" написать так: "TLB имеет важное значение как в разработке, так и в работе приложений" или "Информация, содержащаяся в TLB, имеет важное значение как в разработке, так и в работе приложений".

И новая формулировка будет справедлива исключительно для Visual Basic. Потому что TLB имеет важное значение только если вы используете эту технологию (вопрос вкуса). Это как раз нарушение НТЗ: я прикопаюсь — «С чего это вдруг? Я могу успешно разарабывать приложения без TLB. И работать они будут без TLB? С какиз щей она тогда имеет важное значение?». А та формулировка, которая там сейчас, (моя) говорит лишь, что она содержит важную (для разработки и функционирования программ) информацию. И к этому не подкопаешься — она действительно важную и необходимую для этого информацию содержит.

То, какая именно (или "какого вида") сущность определяется, устанавливает вид типоописания. В соответствии с этим, вид типоописания является важной характеристикой для того-то, того-то."

Я против конструкции «То, какое ..., определяет <то-то>». Более того, при такое построение предложения намекает, что «вид типоописание» является термином. Тогда как у меня это не термин. Смотри далее:

Кстати, я правильно понял из твоих слов, что термин (что следует из выделения его курсивом) вид типоописания был введён тобой? Не орисс ли это? Яндекс выдаёт только твою тему в блоге на vbstreets, в которой я употребил это словосочетание, а Google - только на обсуждаемую статью. И по слову "типоописание" тоже ссылки только на vbstreets (твои посты) и эту статью.

Нет, не следует, курсивное начертание используется как акцент на словосочетании (ср.: «—Он был на мероприятии! —А я говорю: не был!» и «—Он был на мероприятии! —Нет, это был его брат-близнец!»).

В данном случае, «вид типоописания» — просто перевод названия параметра и его значения. Не термин. То не что это не термин прежде всего следует из его нецельности. Т.е. это просто два слова, словосочетание, где слово «вид» — обычное русское слово, а типоописание — перевод «термина» (хотя и это не истинный термин) TypeInfo.

Мне кажется, что требование «сначала расшифровка, потом упоминание» более важно , чем два других требования, потому что фактически употребление потенциально непонятного термина приводит к потенциально непонятному всему предложению

Если бы это был термин, возможно. Но в данном случае имеется в виду прочто вид, род, тип (тавтология :( ) типоописания. В первом случае можно было бы написать «название идентификатора зависит от вида типоописания, который зависит от того, чем является описываемая сущность, а определяется значением параметра TypeKind, который к тому же переводится тоже как «вид типоописания». Но это слишком неуклюже, к тому же, читающий будет везде фразу «вид типоописания» принимать за перевод названия параметра TypeKind. Будет коллизия терминов, и от неё никуда не деться.

Про столбец "Type Kind". Когда я читал статью, мне показалось непонятным значение этого столбца. Я просто высказал свой независимый взгляд, заключающийся в том, что название этого столбца потенциально может ввести в заблуждение (в которое я и попал, и результатом была ошибочная правка). Ты можешь учесть мой независимый взгляд со стороны, а можешь не учитывать. Если ты не хочешь упоминать конкретные параметры функций в разделе "Структура", то объяснение смысла столбца можно сделать в примечании. Кстати, ещё одна причина, по которой мне "Type Kind" показался употреблённым ранее английским термином, а не идентификатором - это то, что в идентификаторах (параметрах функций, именах переменных) обычно не бывает пробелов.

Названия идентификаторов не содержат пробелов, потому что при анализе исходного кода будет невозможно при таком раскладе обнаружить, где кончается идентификатор. В статье на естественном языке такой проблемы нет. К тому же, это не только параметр типоописания, это ещё и одноимённый Enum. При этом параметр называется typekind, а энум — TYPEKIND. Поэтому, вместо конкретного спеллинга, отсылающего либо к параметру, либо к энуму, я привёл заголовок с проблем и сконвертировал его в Proper-Case (традиция для англоязычных заголовков).

"Можно сказать" придаёт утверждению неопределённость, расплывчатость, неуверенность ("можно сказать, а можно и не говорить"), неоднозначность, что является уходом от научного стиля, поэтому я его и убрал. "Существует мнение" - намного лучше, и действительно улучшает нейтральность.

«Существует мнение» уместно, когда утрвеждение по крайней мере не очевидно с первого взгляда. Например, треугольник можно рассмотреть как трапецию, у которой одно из оснований равно нулю. В этом случае:

• Формула площади трапеции $S=h{\frac {a+b}{2}}$ («полусумма оснований на высоту») при этом (a = 0) превращается в формулу площади треугольника $S=h{\frac {b}{2}}$.
• Формула площади трапеции (вписанной в окружность) aka Формула Брахмагупты $S={\sqrt {(p-a)(p-b)(p-c)(p-d)}}$ превращается при этом (a = 0) в формулу Герона: $S={\sqrt {p(p-b)(p-c)(p-d)}}$.

А теперь фраза: «Можно сказать, что формула Герона является частным случаем формулы Брахмагупты» «Можно сказать, что формула Брахмагупты является обобщением формулы Герона». Теперь представь, как бы глупо выглядели эти же фразы, но со словами «существует мнение»? Скажешь, что «можно сказать» придаёт фразе расплывчивость? Наверняка ты скажешь, что можно вообще убрать «можно сказать» из обоих фраз. В этом случае — да, потому что треугольник и трапеция являются понятиями одноковой «ширины». То есть в Эвклидовой геометрии они либо оба существуют (2-хмерное пространство или пространство большей размероности), либо оба не имеют смысла (одномерное пространство).

В случае с заголовочными файлами и библиотеками типов всё не так. Во-первых, понятие «Библиотека типов» имеет силу даже не просто в пределах только ОС Windows, а только в пределах технологии ActiveX. А понятие «заголовочный файл» — кроссплатформенное. Даже при написание программ для экзотических микропроцессоров оно имеет полную законную силу. То есть во весь голос заявлять, что TLB продвинутый аналог заголовочных файлов я бы не стал. Некая умеренная доля «неуверенности» здесь необходима, я считаю. Кроме того: никто целенаправленно не старался создать аналог заголовочных файлов. Приследовали совсем другие цели (см. причины возникновения). Просто так получилось. Но, хоть утверждение и верно безо всяких колебаний во мнении (то есть никаких «существует мнение ..., но существует также и другое мнение ..., а ещё третье» — такого нет), никто не акцентирует на это особого внимания, никто не рвётся заменять заголовочные файлы библиотеками типов. Поэтому именно «можно сказать». А ещё, заголовочные файлы — это просто включаемые файлы. В них обычно помещают объявления типов, прототипов функций, но можно помещать и код функций (реализацию). А можно всё то, что находится в заголовных файлов, поместить в основной source-файл.

побочно выполняет ненужную функцию разделения. Для специального разделения используется запятая, а тут разделение происходит как побочное ненужное действие. Кроме того, вставленная сноска прерывает мысль. Лучше, чтобы читатель дочитал до конца мысли, а потом уже смотрел примечание к мысли

Не согласен насчёт разбивания и прерывания мысли. Что же касается «дочитал до конца» — так ведь никто не заставляет кликать по сноске сразу, как только глаза на неё натыкаются. Встретил непонятное слово, заметил сноску, решил дочитать до конца (вдруг смысл придёт?), смысл не пришёл — вернулся и кликнул на сноску.

А из вредности правят только вандалы.

Ну так не правь. Если тебя так волнует стиль, если ты так печёшься о русском языке (я тоже обо всём это волнуюсь), что готов вносить правки, коверкающие смысл, ну так поставь ты лучше правку «эта статья нарушает нормы энцикл. стиля» и давай придём к согласию здесь и в конце внесём нужные правки. Лучше плашка и правильный смысл, чем энцикл. стиль, но со смысловыми искажениями.

--Firehacker 14:32, 7 февраля 2010 (UTC)

Кстати, по твоему, утверждение, что «Конституция — важшейший, первостепеннейший документ», — это тоже нарушение НТЗ?

В таком виде - да. Если сказать "важшейший, первостепеннейший документ в правовых системах многих государств", то уже будет нейтрально.

Эта непредвзятая «кишка» лучше предвзятого слова «важнейшей»?

Конечно лучше. Видишь, ты сам заменил "важнейший" на "важнейший в вопросе". А я предлагал уже такой же вариант, но без "кишки": "То, какая именно (или "какого вида") сущность определяется, устанавливает вид типоописания. В соответствии с этим, вид типоописания является важной характеристикой в вопросе определения дальнейшего хода анализа типоописания, сути описываемой им сущности, а также значения всех его прочих характеристик"

И новая формулировка будет справедлива исключительно для Visual Basic.

Мне кажется, обе формулировки будут справедливы только для Visual Basic. "TLB содержит ряд важной информации, необходимой в процессе работы приложений". Нет, в случае приложений на Си информация в ней не будет необходима. По-моему, здесь просто нужно заменить "приложений" на "ActiveX-серверов" (или что-то типа того) и всё будет ок. Всё, короче, уже не предлагаю изменять эту фразу: там указано "где оно важно" сразу же во второй половине предложения, но только в другой, разнообразящей форме.

Насчёт "вида типоописания". Предлагаю полностью избавится от этого полутермина, который ещё к тому же попахивает ориссом. Ты его сам называл "ущербным". Вот написал вариант раздела "Логическая структура" вообще без его употребления:

Библиотека типов является трёхуровневым иерархическим хранилищем: вершиной иерархии является сама библиотека (англ. Type Library), представляющая собой набор типоописаний (англ. Typeinfo [вот тут написано именно слитно: [1]]), являющихся, в свою очередь, контейнерами элементов третьего уровня — членов (англ. Member).

Все три типа элементов имеют одинаковый набор базовых характеристик:

• числовой идентификатор,
• имя (англ. Name),
• краткое описание (англ. Documentation String),
• файл справки (hlp или chm) и идентификатор справочной статьи (англ. Help File Name и англ. Help Context ID).

Для библиотек и типоописаний идентификаторы статистически уникальные 128-битные, а для членов — 32-битные (уникальные в пределах одного типоописания). Идентификатор библиотеки называется LIBID, члена — MEMBERID. [убрал отсюда то предложение к чёртовой матери: ВСЁ из-за него едет]

Каждое типоописание определяет некую сущность. В библиотеке типов могут описываться сущности 8-ми различных видов:

Сущность	Члены	typekind[1]	Название идентификатора
Перечисление (Enum)	Константы	TKIND_ENUM	—
...	...	...	...

На третьем столбце поставить примечание, что, мол, это значение параметра при вызове такой-то функции в таких-то условиях, который определяет вид описываемой сущности. Там же упомянуть про его важность в вопросе определения дальнейшего хода анализа типоописания и т. д. (Ведь всё-равно ты про параметры функций не хочешь писать в разделе "Структура", а важность-то именно у параметра (ведь не скажешь же "вид сущности, описываемой типоописанием, является важной характеристикой типоописания"), выходит: ты важность не должен писать в разделе "Структура")

Наверняка ты скажешь, что можно вообще убрать «можно сказать» из обоих фраз.

В английской Википедии так и написано: Heron's_formula#Generalizations

Может быть "по выполняемым функциям библиотеки типов идейно близки к заголовочным файлам"? Аналог - это уже всплывает какая-то конкуренция и, возможно, взаимозаменяемость, а тут просто идеи близки? Тут же объективно получается, что функции у них значительно пересекаются.

Ну так не правь.

Я руководствовался правилом "Правьте смело", так как был почти полностью уверен, что делаю всё правильно.

--Александр Дмитриев 07:45, 8 февраля 2010 (UTC)

Конечно лучше. Видишь, ты сам заменил "важнейший" на "важнейший в вопросе".

Не вопросе, а в достижении цели, в действии. Фишка в том, что этот «вопрос», «цель», «действие» — единственно возможное с TLB. Единственное предназначение TypeInfo — выдать нам максимум информации о сущности. Это невозможно сделать, не зная TypeKind. Нельзя получить никакую информацию. Вернее получить можно, но истолковать (что важнее, чем просто получить) — нет. Потому что TypeKind и определяет, как толковать информацию.

Мне кажется, обе формулировки будут справедливы только для Visual Basic. "TLB содержит ряд важной информации, необходимой в процессе работы приложений". Нет, в случае приложений на Си информация в ней не будет необходима.

Отсутствие логики detected. В случае приложения на Си эта информация будет столь же необходимой и важной. Но описана она будет возможно не в TLB. Но, где бы она ни была описана, она: а) всегда остаётся важная и б) она содержится в TLB. Так что фраза без всяких сомнений верна, и она верна безотносительно каких либо языков.

А я предлагал уже такой же вариант, но без "кишки": "То, какая именно (или "какого вида") сущность определяется, устанавливает вид типоописания. В соответствии с этим, вид типоописания является важной характеристикой в вопросе определения дальнейшего хода анализа типоописания, сути описываемой им сущности, а также значения всех его прочих характеристик"

Плохой вариант. Во-первых конструкция «то, какая ... .., зависит от ...» — гораздо более не энциклопедична, чем то, что ты у меня повырезал. Во-вторых, я уже сказал, что «вид типоописания» ни разу не термин. В твоём варианте «устанавливает вид типоописания» словосочетание «вид типоописания» стоит в такой позиции, в какой обычно стоят термины или названия параметров. А это не параметр. Вид — это понятие, связанное с наблюдением. Вид не может устанавливать или определять что-то. Вид типоописания зависит от того, что определяет типоописание. А не «то, что определяет типоописание, зависит от вида»

Насчёт "вида типоописания". Предлагаю полностью избавится от этого полутермина, который ещё к тому же попахивает ориссом. Ты его сам называл "ущербным".

Это не термин вообще. Почитай статью Зубчатая_передача. Там есть такой фрагмент:

Реечная передача — один из видов цилиндрической зубчатой передачи, радиус делительной окружности рейки равен бесконечности.

Вот мой «вид типоописания» настолько же не термин, насколько же не является им «вид цилиндрической зубчатой передачи». Это просто слово, синоним слова «разновидность». НЕ ТЕРМИН ЭТО. Ты просто не можешь ещё понять, где в статье это просто два слова, а где — перевод названия параметра.

Предлагаю перевести:

Type Kind — parameter that determines kind of type.

Уверен, ты переведёшь так:

Вид типа — параметр, который определяет вид типа.

Видишь, что в переводе «Type Kind» (название параметра, термин с натяжкой) и «kind of type» (просто грамматическая конструкиц, вовсе не термин» слились в единое «вид типоописания»? Научись, пожалуйста, определять и отделять: где в этой статье слово «вид» — часть переведённого название параметра (первый случай), а где — просто русское слово.

Ты его сам называл "ущербным"

Всё верно, это историческая ущербность от Microsoft. Такая же, как и с понятием интернет-радио. Или (ещё от Microsoft) нестраничная страница.

Делов в том, что термин Type Info следовало бы перевести как информацию о типе. Но проблема в том, что типоописание описывает не только то, что можнло назвать типом, как было, вероятно, на этапе формирования этого термина, но и модули, которые типами ну никак не являются, и никакие натяжки тут не помогут. Поэтому говорить об «информации о типе» — ещё раз вводить кого-либо в заблуждение (коллизий различных в данной тематике и так полно). Вообще говоря, правильным решением (для Microsoft) было заменить Type на Entity. Тогда было бы EntityInfo (и перевод был бы дословный: информация о сущности, а не «сущностиописание») и вместо Type Kind было бы Entity Type (тип сущности, а не «вид типоописания») и вообще не было бы никаких коллизий терминов.

Но увы, официальный термин являются несколько обсурдным и посему я его называю ущербным.

(англ. Typeinfo [вот тут написано именно слитно: [1]])

Там много что слитно написано, например coclass и dispinterface тоже. Но и раздельное написание там так же часто встречается: "type+info"+site%3Amsdn.microsoft.com

Они не особо волнуются по поводу единого написания.

• числовой идентификатор,

Категорически против! GUID-ы не являются числами. Над числами определены различные арифм. операции, а над гуидами такие не определены. Так что эти идентфикаторы совершенно не являются числовыми. И на надо говорить, что гуид можно представить в виде последовательности чисел, и поэтому он числовой. Всё можно представить в виде последовательности чисел, поэтому тогда всё сущее — числовое...

[убрал отсюда то предложение к чёртовой матери: ВСЁ из-за него едет]

Так может быть уберём всю статью к чертовой матери? Сэкономим друг-другу время. Я уже тысячу раз пожалел, что написал сюда эту статью.

То, что у некоторых видов сущности идентификаторы имеют своё собственное название — важно. CLSID IID чаще используются, и известны гораздо болееш широкому кругу лиц, чем тот же дейтерий. Ну упомянуть этого, всё равно что написать про дейтерий, не упомянув водород.

Может быть "по выполняемым функциям библиотеки типов идейно близки к заголовочным файлам"? Аналог - это уже всплывает какая-то конкуренция и, возможно, взаимозаменяемость, а тут просто идеи близки? Тут же объективно получается, что функции у них значительно пересекаются.

Не то. Поменяй библиотеку типов на пистолет (или ружьё), а заголовочные файлы — на топор. Оцени получившуюся фразу. «По выполняемым функциями пистолет идейно близок к топору».

Если говорить о топоре как об оружии, то действительно можно сказать, что пистолет продвинутее топора. Между ними есть конкуренция, и взаимозаменяемость есть.. Проблема в том, что пистолет делали для выполнения исключительно одной функции: стрелять пулями. Он делает только это, и ничего больше. Топор не делали специально для того, чтобы убивать, или специально для того, чтобы рубить им что-то, или колоть дрова. Топором можно делать многие вещи. Топор имеет более широкое применение, например, он может работать там, где применение пистолета невозможно, и для тех целей, для каких пистолет совершенно неприменим. Например, некоторые умудряются бриться топором. У пистолета выполняемая функция обуславливается сложной конструкцией (поэтому функция одна), у топора же никакой сложной конструкции нет, есть просто особая форма. Все функции, которые он может выполнять, проистекают из особенностей его формы. Такие применений можно придумать очень много.

Но когда говорят о применении топора как оружие, нельзя не сказать, что пистолет продвинутее топора.

Единственное но: основное применение топора не такое, как у пистолета. В то время как у включаемых файлов основное применение как раз такое же, как и библиотеки типов (описать энумы, структуры, юнионы, псевдонимы, классы, функции, их прототипы).

Конкуренция и взаимозаменяемости в тех пределах, в которые существует понятие TLB — есть. В частности, если бы Microsoft в Platform SDK положила не windows.h, а windows.tlb, разрабатывать приложения «на голых WinAPI» было бы гораздо проще не только сишникам, но и приверженцам всех языков и IDE, которые поддерживают работу с TLB.

Я руководствовался правилом "Правьте смело", так как был почти полностью уверен, что делаю всё правильно.

А по-моему это особый вид преследования. Не дал бы я ссылку, не было бы этих правок.

Во-всяком случае. «правьте смело», но помните, что содержание важнее формы. --Firehacker 11:34, 8 февраля 2010 (UTC)